Real-time-capable and real-time-bound and, in particular, clock-synchronous or isochronous communication and data transmission networks require for their installation a complete specification of the network topology. Examples for isochronous networks, thus networks which ensure a real-time-based or real-time-bound and a synchronous or clock-synchronous and therefore deterministic and optionally equidistant communication or data transmission between at least two of their subscribers, are Profinet IRT, SERCOS III, VARAN or EtherCat.
Since in the industrial environment, the network cabling is mostly carried out from machine to machine, these industrial Ethernet networks are in most cases implemented in a line or ring topology.
In order to achieve deterministic communication properties with Ethernet technology, the access to the communication medium is subject to additional rules. There are different approaches. Some standards reserve the medium completely for real time telegrams, others reserve periods of time for real time telegrams. For such a timing of the media access, but also for purposes of topological address allocation, knowledge of the exact network topology is a requirement.
Accordingly, the operation of a topologically planned RealTime Ethernet (RTE) network requires to plan exactly in advance to which unit of the topologically planned RTE network which unit adjacent to said first unit is connected to which predetermined Ethernet interface (so-called “port”) of said first unit. Moreover, the line length of the connection between two units is often predetermined.
Exact planning in advance relates at least to the logical configuration of the network, in particular regarding the sequence of the data to be transmitted, and also to the physical configuration, in particular regarding the data transmission paths, for optimizing the data transmission in dependence on the topology of the network.
A clock-synchronous or isochronous communication or data transmission by means of topologically planned real time Ethernet networks is in particular required for controlling motions in drive systems (motion control), thus for a motor control, or during positioning processes.
Within the context of this application, communication and data transmission networks, thus such network systems which allow data exchange and therefore communication between subscribers connected by or via said network systems, are simply designated as networks. The mentioned subscribers are in particular computers, programmable logic controllers or other machines or devices, in particular from the field of (process) automation technology such as sensors or actuators which communicate with one another via the network or exchange data between one another and, in particular, also process data.
The control program is preferably structured in a modular manner and preferably comprises for each equipment type and each embodiment of the plant or the device list corresponding program sections for controlling the same, wherein a respective program section can comprise one or a plurality of functional blocks. When executing the control program by the control unit, those program sections are executed which are required for controlling the devices or subscribers actually situated in the plant and thus are connected to the network and to the control unit.
Designated as IO configuration is the definition of the composition of the process data and IO data in a data telegram, in particular in respect of their structure, volume and sequence.
The definition of a topology of the network, that is, the network subscribers and the connections between them or their network interfaces, is part of the physical configuration.
Furthermore, based on at least some information for an RTE network resulting from the logical and physical configuration, RTE communication parameters for the network are additionally calculated through an RTE planning algorithm, said parameters defining in particular transmitting and receiving times, thus times at which a data telegram is to be transmitted from a first to another network subscriber.
For planning or projecting the logical and physical configuration of a real-time-capable and isochronous network within the planning and implementation of the network and for the start-up of the same, for example after a new construction or reconstruction of a (process) automation plant, it is known that a person familiar with the project planning of such networks or plants uses a so-called engineering system. Such an engineering system is usually formed by an engineering tool which is implemented in a data processing unit, and in the context of which it is also possible to run an RTE planning algorithm for calculating RTE communication parameters for the RTE network. For completion of this planning step, the RTE communication parameters are calculated with the RTE planning algorithm. Subsequently, the engineering system, which is at least temporarily connected to the network for this purpose, transmits the following information to the control unit: a scheduler or a control program, a device list, an IO allocation, an IO configuration, a target topology as specification for setting up the network with its subscribers and the connections, as well as the further RTE communication parameters. In general, such engineering systems are known and available for a multiplicity of network types, in particular Ethernet-based networks.
From this information available to the control unit, in particular from the target topology and the RTE communication parameters, those portions are transmitted to each subscriber which are relevant for the respective subscriber. The subscribers of the network then check automatically if their direct neighbor subscribers correspond to the planned subscribers and network interfaces according to the target topology. If each subscriber has identified the respective correspondency, the target topology can be activated as actual topology and the network with its subscribers or the plant with its devices can be put in operation. However, in the case that one of the subscribers, during the check of its neighbors, identifies deviations of the actual state from the target topology, the subscriber in the known prior art transmits a diagnosis alarm to the control unit which disables the startup of the network until the cause is corrected.
FIG. 1 schematically shows this known solution, the physical configuration being represented by the target topology and the logical configuration being represented by the IO allocation, the latter being illustrated by means of arrows between the device list and the control program.
A disadvantage of this solution according to the prior art, illustrated in FIG. 1, is that the control program is configured such that individual devices, thus plant or machine parts and functions, are mapped by corresponding program modules so that a plurality of variants of a plant or machine can be controlled by the control program, but that with each change of the actual topology or the actual state of the network, for example due to converting the plant, removing and/or adding devices, especially the target topology has to be adapted accordingly by means of the engineering system and, together with the RTE communication parameters recalculated based on said adaptation, has to be transmitted again to the control unit from where the subscribers involved as well as their neighbor subscribers receive the respective portions of the new information, in particular of the target topology and the RTE parameters, before the network or the plant in the changed state can be put in operation again.
According to a further known solution for projecting or planning a real-time-capable and isochronous network, it is envisaged to provide in the control unit a plurality of alternative configurations and in particular the respective target topologies and optionally the associated RTE parameters according to the possible variants of a plant or machine, so that these alternative configurations, without needing an engineering system again, can simply be selected according to the respective actual topology or the respective actual state of the network of a certain variant of the plant, for example via a man-machine interface allocated to the control unit, in particular via a simple display and operating unit connected to the control unit.
However, one problem of this solution is that for machines comprising many variants, for example, in the case of modular machine tool designs where the number of machine variants is almost unlimited, it is no longer feasible to provide in advance the necessary configuration inclusive the target topology and the RTE communication parameters for each possible variant in the control unit.
Another known solution according to the German patent application DE 102006042949.4 is based on the actual topology of the network and quasi dispenses with the specification of a target topology. A so-called topology server in a communication network with further main subscribers is programmed here in such a manner that it checks if a network-internal event has occurred and, in the event of the occurrence of the network-internal event, automatically determines the current actual topology, and, based on communication relations allocated to the main subscribers, automatically determines topology-dependent communication data and automatically transmits to each main subscriber that portion of the topology-dependent communication data that is relevant for the respective main subscriber.
This solution offers a higher flexibility with respect to the previously described approach. However, a disadvantage is the safety risk resulting from the abandonment of a target topology that is independent of the actual topology or actual state of the network. Without the possibility of a target/actual-comparison, errors such as, for example, wrong wirings or the absence of at least one device which, according to a certain variant of the machine or plant would be provided, cannot be reliably detected. Furthermore, according to this solution it is provided that an operator can trigger the automatic configuration process from the outside; however, there is no other possibility for influencing the configuration.
Thus, although solutions are known which at least to some extend allow a dynamic adaptation of the physical configuration to changed network topologies, no dynamic adaptation of the logical configuration to changes with regards to the IO allocations and/or IO configurations is known. Rather, IO allocations and/or IO configurations are always fixedly predefined by means of an engineering system and, in the case of an adaptation, usually require again the aid of the engineering system. This is impractical if, for example, a device of a plant or machine has to be replaced due to a defect and the new device offers the same functions as the old device but requires, for example, a different process or IO data wiring and/or a different composition of the process or IO data in a data telegram because it is a different type and/or is made by a different manufacturer than the old device.
Using an engineering system can usually be managed only by adequately specialized personnel and thus can overtax the operator of a plant.
It is common to prepare this planning by means of software-based tools which, e.g., allow a graphic illustration and editing of the network topology. FIG. 4 shows such an exemplary topology.
The networking of the topology that has to be completely defined in advance entails restrictions. A PROFINET system ensures, for example, that an RTE system starts only if all installed neighbor devices also correspond to the neighbor devices planned in advance; here, not only the names of the devices, but also the assigned Ethernet interfaces have to be consistent with the planning. The consequence of this is that errors in the installation phase or after a device replacement can result in that a machine or an entire plant is not able to start. This condition can only be resolved by diagnosing the difference between the target and the actual configuration as well as by a correction of the installation. In previous methods, this is checked in that each device receives information about the planned neighbor device including the respective port information. If differences are detected in this connection between the actual configuration and the target configuration planned in advance, a diagnosis is triggered which usually results in a stop of the user program and thus possibly results in a stop of the entire plant.
Exact planning of the target topology via an engineering system requires an accurate determination by the user on how the devices and their Ethernet interfaces are to be installed. In the case of the normal Ethernet, due to the “plug & play” approach which is enabled through a dynamic port addressing, these considerations and also the installation are unusual.
In summary this means that the installation of the PROFINET network has to correspond exactly to the planning. At the same time, the installer also has to meet the specifications exactly regarding the interfaces to be selected.
In practice, this is not always easy to do because due to local conditions it might be necessary during the installation to deviate from the planning. These deviations result in increased expenses during the adaptation of the planning because as a result of this, the interface assignment has to be revised again and the network has to be reconfigured.
Also, when replacing one of the devices, for example due to maintenance work or a defect, it occurs again and again that a wrong selection of the network interface causes a time-consuming trouble shooting. It can in particular happen that an error occurs during a device replacement because the network interface can not be allocated to the previously installed interface. The use of PROFINET IRT in practical tests has demonstrated that mixing up ports is a very common error cause.